I think we should also change this page:

ultimately, whatever value the user inputs here ends up as tproxy's min_individual_miner_hashrate config parameter, while we're labeling it as "total expected hashrate"

this leads to a misleading vardiff UX... let's analyze a few scenarios:

scenario A

the user has 10 workers of 1 TH/s each

in order for tProxy to be launched correctly, min_individual_miner_hashrate must be set with 1 TH/s

but this UI induces the user to set 10 TH/s

scenario B

user has 3 workers of different hashrates:

• 500 GH/s
• 5 TH/s
• 100 TH/s

in order for tProxy to be launched correctly, min_individual_miner_hashrate must be set with 500 GH/s

but the current UI induces the user to set 105.5 TH/s

cc @GitGab19

I think we should also change this page:

ultimately, whatever value the user inputs here ends up as tproxy's min_individual_miner_hashrate config parameter, while we're labeling it as "total expected hashrate"

this leads to a misleading vardiff UX... let's analyze a few scenarios:

scenario A

the user has 10 workers of 1 TH/s each

in order for tProxy to be launched correctly, min_individual_miner_hashrate must be set with 1 TH/s

but this UI induces the user to set 10 TH/s

scenario B

user has 3 workers of different hashrates:

* 500 GH/s

* 5 TH/s

* 100 TH/s

in order for tProxy to be launched correctly, min_individual_miner_hashrate must be set with 500 GH/s

but the current UI induces the user to set 105.5 TH/s

cc @GitGab19

I think this also depends on the channel aggregation.

Currently the UI configures tProxy in NON aggregated mode, so it opens 1 channel per Sv1 client connected. So in the current scenario you're correct, and we should ask users to insert the lowest hashrate device it's gonna be connected to the tool.

The other option we have is to change the UI to configure tProxy in aggregated mode, but this introduces other newer UX challanges, and I would do it later.

Still, even in the current NON aggregated mode, it's better to have the total amount of hashrate inserted by the user, than starting tProxy with the default value.

TLDR: I'm not sure we really need to change this page, but we should make it clear that it might make time to see the first share, while speeding up the vardiff updates as you stated in stratum-mining/sv2-apps#396 (comment)

Ok so this is the outcome of this PR, for discussion above, we can create a new issue.